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EITLE 



IMobile communications system and method thereof 



(57) Providing a network communications system, 
which extensively supports a mobile temiinai (12). A 
proxy CM (24) being a router (24) Is arranged between 
a con-espondent temiinai (25) (CN) and a home agent 
(26) which directly coresponds to the con-espondent 
temilnal (25) (CN). The CN (25) accesses the proxy CN 
(24) when receiving a service using the Mobile IP. The 



CN (25) is authenticated by a link layer authenticating 
sen/er (23) which references a sen/ice profile DB (27), 
and makes a connection to a network (20). Communi- 
cation with a mobile tenninal (12) (MN) being a commu- 
nication partner is made via the proxy CN (24). In addi- 
tion, a packet transmission by tunneling is performed by 
the proxy CN (24). 
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Description 

Background of the Invention 

1 . Technical Field of the Invention 

[0001] The present invention relates to a mobile com- 
munications system, and particularly to a network, 
which can accommodate a mobile terminal (a mobile 
node such as a portable PC, etc.) that moves between 
sub-networks. 

2. Prior Art Technology 

[0002] Recently, the volume of IP packet traffic has 
been sharply increasing with the rapid expansion ot the 
Internet. Furthemiore, with the popularization of cellular 
phones, IMT-2000 (International Mobile Telecommuni- 
cations 2000) has been standardized, so that high- 
speed IP communteation in a mobile environment ap- 
pears to be becoming popular. Despite such rapid tech- 
nical innovation, enhancement of IP communication, 
that is, a technique for implementing a value added serv- 
ice such as QoS (Quality of Service) for each terminal 
or load distribution of W\/VW (World Wide Web) traffic 
across multiple servers on an entire network does not 
seem to be maturing fully although it is in potential de- 
mand. 

[0003] US vendors such as Cisco, 3com, etc. have 
taken the initiative In proposingthe concept of PBN (Pol- 
icy-Based Networking) as a framework for controlling an 
IP network. With the PBN, a policy sen/ersets operation 
policies of a network (data used to provide a service to 
a user) in a network device group, which Implements 
services such as QoS, etc, by referencing the policies. 
However, once a setting of a policy for each mobile ter- 
minal (setting of a service to be provided to each mobile 
tenninal) is adopted and when a policy is added/ 
changed, policy setting must be updated in all of the net- 
work devices which can possibly accommodate a mo- 
bile terminal, this leads to an increase in the policy set- 
ting process amount in the entire network. Furthermore, 
to apply the infomnation notified by the PBN to a funda- 
mental service stipulated by an individual mobile IP ter- 
minal, etc., the Information must be made as a specifi- 
cation and examined in the situation of Implementation 
lo be suitable for each service. 

[0004] Fig. 25 exemplifies quality control in a network 
with a poltey according to a conventional technique. 
[0005] Exemplified here is a method like PBN (Policy 
Base Network) with which a policy server & NMS (Net- 
ware (Management System) makes a service negotia- 
tion with a user, and an admission control for each user 
is provided in a fixed network. With the PBN, a policy 
server distributes network operation policies (control pa- 
rameters) to a network device group (including a router, 
etc.) and sets them in the group. The network device 
group implements services such as GoS (Quality of 
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Service: service quality control), etc. by referencing the 
above described policies when controlling packets. 
[0006] However, if an attempt is made to set a policy 
dedicated to each mobile terminal, a problem may arise. 
That is, when a policy is added/changed, policy setting 
is requiredto be made in all of the network devices which 
can possibly relay packets transmitted/received by a 
mobile tenninal. This leads to a great increase in the 
amount of policy setting processes in an entire network. 
In other words, network devices such as a router, etc. 
must hold a huge number of pieces of poltey data for 
respective temninals. This is Impractteal as a service 
controlling method for each terminal. 
[0007] In an IP network, in whk:h voice and data com- 
munications are integrated, and to which various types 
of temninals are connected, a method such as Int-Serv 
(RSVP: see RFC 2205 of Intemet Engineering Task 
Force, Network Working Group) or Diff-Serv (see RFC 
2475 of Internet Engineering Task Force, Network 
Working Group) is proposed as a means for implement- 
ing QoS in order to protect traff k: which is sensitive to a 
delay or traffic to which a higher business priority is as- 
signed. Above all, the Diff-Serv method having a small 
overhead is considered most effective for a carrier net- 
work or a backbone network (a principal network con- 
necting network of the Intemet). However, this method 
requires policy setting in network devices on a path. Ad- 
ditionally, with this method alone, network management 
becomes troublesome. 

[0008] Therefore, the concept of PBN (Policy-Base 
Networking) with which a server called a poltoy server 
collectively sets policies in network devices was pro- 
posed. However, in a seamless global network com- 
posed of various providers and carriers supporting mo- 
bile tenninals, ail of the local networks are required to 
detemnine a policy for every user who can possibly make 
a connection, and to set infonmation In network devices. 
The only way to implement this detemriination and set- 
ting with the PBN is to locally hold the policy infomnation 
of all users or to preset the Infomnation in potential net- 
work devices. 

[0009] It is extremely inefficient and impractical to per- 
form these operations for users totaling as many as hun- 
dreds of millions. Furthermore, continuously holding the 
policy infomnation of all users in network devices re- 
quires an increase in the memory amounts of the net- 
work devices, so that the load for processing these huge 
amounts of infomriation becomes heavier, leading to 
degradation in throughput. 

[0010] Inversely, if a processing method for making 
an inquiry to a policy server in all cases is adopted, the 
overhead of making an inquiry to a policy server is in- 
cun-ed, and the possibility that the SLA (Service Level 
Agreement) cannot be complied with may increase. 
[001 1 ] An object of the present invention is to provide 
a communications system of a network that extensively 
supports a mobile temninal. 
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Summary of the Invention 

[0012] A mobile communications system according to 
the present invention is a system, which enables a mo- 
bile temninal connecting to a network composed of a plu- s 
rality of sub-networks to be provided with communica- 
tion similar to that provided in a first sub-network when 
connecting In a second sub-network, even after moving 
from the first to the second sub-network. This system 
comprises: a conrespondent temiinal making a commu- io 
nication with the mobile terminal; an authenticatlng:unlt 
authenticating the correspondent temninal; a setting unit 
setting communication parameters that the con-espond- 
ent temninal requires to make a communication with the 
mobile terminal when the mobile terminal moves from is 
the first to the second sub-network; and a communicat- 
ing unit making a communication between network con- 
trolling devices so as to set the communication param- 
eters. 

[0013] A mobile communications method according 20 
to the present invention is a method, for use in a network 
including a correspondent terminal making a communi- 
cation with a mobile terminal, which enables the mobile 
tonnlnal connecting to a network composed of a plurality 
of sub-networks to be provided with communication sim- 25 
ilar to that in a first sub-network when connecting In a 
second sub-network, even after moving from the first to 
the second sub-network. This method comprises the 
steps of: (a) authenticating the correspondent terminal; 
^: (b) setting communications parameters that the con-e^ 30 
u.spondent terminal requires to make a communication 
with the mobile temninal when the mobile terminal 
moves from the first to the second sub-network; and (c) 
making a connmunication between network controlling 
devices so as to set the communication parameters. 35 
[001 4] A router according to the present invention ac- 
commodates a temninal which makes a communication 
with a mobile temninal, hunts binding infonnatlon about 
the mobile temninal, which is transferred from the home 
agent of the mobile temninal to the temiinal, and proc- 40 
esses data packets from the temninal to the mobile ter- 
minal based on the binding infomnation. 
[001 5] According to the present Invention, devfces ar- 
ranged within a network make a communication for 
managing or setting communication parameters re- 45 
quired when a mobile terminal moving between sub-net- 
works communicates with a correspondent terminal 
while straddling the sub-networks, and the con-espond- 
ent terminal communicates with the mobile terminal via 
these devices. Accordingly the correspondent terminal so 
does not need to comprise a particular capability to re- 
ceive a communication service with the mobile terminal, 
so that a heavy processing load is never imposed on the 
correspondent temninal. Therefore, various terminals 
possessed by users are available as a correspondent ss 
temninal, and the users can easily receive a communi- 
cation with a mobile terminal. 
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Brief Description of the Drawings 
[0016] 

Fig. 1 explains a Mobile IP; 
Figs. 2A and 2B schematically illustrate communi- 
cation paths, which are shown in and extracted from 
Fig. 1; 

Fig: 3 shows an example of a network configuration 
according to a prefen-ed embodiment of the present 
invention; r 

Fig. 4 exemplifies a service profile; 
Fig. 5 shows the process for registering a CN (Cor- 
respondent Node) to a proxy CN. 
Fig. 6 exemplifies a sequence showing the funda- 
mental procedure for registering the CN to the proxy 
CN; . 

Fig. 7 exemplifies a sequence showing the method 
for managing individual service control data within 
the proxy CN; 

Fig. B.exemplifies a sequence showing a preferred 
embodiment of the method for managing a visit 
state of the CN (No. 1); 

Fig. 9 exemplifies a sequence showing the pre- 
ferred embodiment of the method for managing the 
visit state of the CN (No. 2); 

Fig. 10 exemplifies a sequence showing another 

preferred embodiment of the method for managing 

the visit state of the CN (No. 1 ) ; 

Fig. 1 1 exemplifies a sequence showing another 

preferred embodiment of the method for managing 

the visit state of the CN (No. 2); 

Fig. 12 exemplifies a sequence showing another 

preferred embodiment of the method for managing 

the visit state of the CN (No. 3); 

Fig. 13 shows a first prefen^ed embodiment of the 

nnethod for an^nging a proxy CN functional group; 

Fig. 14 shows a second preferred embodiment of 

the method for arranging the proxy CN functional 

group; 

Fig. 15 shows a third preferred embodiment of the 
method for arranging a proxy CN functional group; 
Fig. 16 exemplifies a flowchart explaining the IP 
sen/ice control message process in the preferred 
embodiment shown In Fig. 13 (No. 1) ; 
Fig. 17 exemplifies a flowchart explaining the IP 
sewice control message process in the preferred 
embodiment shown In Fig. 13 (No. 2); 
Fig. 18 exemplifies a flowchart explaining the IP 
sen/ice control message process in the preferred 
embodiment shown in Fig. 14 (No. 1); 
Fig. 19 exemplifies a flowchart explaining the IP 
sen/ice control message process in the preferred 
embodiment shown in Fig. 14 (No. 2); 
Fig. 20 exemplifies a flowchart showing the IP serv- 
ice control message process in the preferred em- 
bodiment shown in Fig. 14 (No. 3); 
Fig. 21 exemplifies a flowchart showing the IP serv- 
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ice control nnessage process in the preferred enn- 
bodiment shown In Fig. 14 (No. 4); 
Fig. 22 exemplifies a flowchart showing the IP serv- 
ice control message process in the preferred em- 
bodiment shown In Fig. 15 (No. 1); ' 
Fig. 23 exemplifies a flowchart showing the IP serv- 
ice control message process in the preferred em- 
bodiment shown in Fig. 15 (No. 2); 
Fig. 24 exemplifies a flowchart showing the IP serv- 
ice control message process in the preferred em- < 
bodiment shown in Fig. 15 (No. 3); and 
Fig. 25 exemplifies the conventional quality control 
using policies In a network. 

Detailed Description 

[0017] The present Invention assumes the technique 
recited In the U.S. Patent Application No. 09/672,866 
(the Japanese Patent Application No. 11-276703), 
which is incorporated by reference . Hereinafter, the 
contents of this application will be briefly described. For 
further details, please refer to the specification Included 
in the application. 

[0018] This Patent Application provides a framework 
of a service control, which is based on a Mobile IP ar- 
chitecture implemented by combining the Mobile IP that 
is stipulated by RFC 2002 and an AAA (Authentication, 
Authorization, and Accounting) system that is currently 
being reviewed by IETF (Internet Engineering Task 
Force: a leading standardization organization for the In- 
ternet; Internet Engineering Task Force, Network Work- 
ing Group RFC 2002: IP Mobility Support. October 
1996:), for effectively setting necessary infonnation 
(polteies) in a global network straddling providers from 
a user profile that Is managed in a centralized manner. 
[0019] With the technique recited in this application, 
a database for storing inf omnation set in a network de- 
vice in user units is an-anged in the AAA system, and 
the function for extracting the information from the iden- 
tifier (NAI: Network Access Identifier) of a user when an 
authentication request is made, and for selecting and 
notifying the information required by the functional enti- 
ties stipulated by RFC 2002, FA (Foreign Agent. Its de- 
tails will be described later), and HA (Home Agent. Its 
details will be also described later). Furthenmore, the 
protocol used for a communication between functional 
entities is expanded so that the information required by 
each entity can be notified, the HA and the FA are 
equipped with the function for caching the infonnation 
notified from the AAA system, and a f unctic n for control- 
ling the infonnation setting in a network device and 
packet editing is added. These functions are integrated 
with the registration procedure of the Mobile IP, handoff 
(handover) during a move, or the procedure for optimiz- 
ing a route, so that it becomes possible to set valid policy 
infonnation while a user accesses a network. 
[0020] Accordingly, the present Invention is explained 
by assuming the Mobile IP. For details of the Mobile IP. 



please see the following references. 
[0021 1 "Mobile I P: The Internet Unplugged" written by 
James D. Solomon, supervised and translated by F. Ter- 
aoka and J. Inoue. and published by Pierson Education, 
? Co. 

[0022] Acronyms that appear in the explanation of 
preferred embodiments are explained below. 

- MIP (Mobile IP) 

0 

[0023] Mobile I P protocol stipulated by RFC 2002 and 
its all future expansions. 

- AAA protocol 

rs 

[0024] Protocol used by an AAA system. The present 
invention does not detennlne a protocol to be used. 
However, the prefen^ed embodiments assume the use 
of DIAMETER protocol (thai is currently being reviewed 

20 by IETF, and Is obtained by expanding the RADIUS pro- 
tocol for authentication and accounting, which Is most 
frequently used by Intemet service providers). The AAA 
protocol is available as any protocol that can transmit 
the information about authentication, authorization, ac- 

2S counting, and policies. 

- Database retrieval protocol 

[0025] Protocol for retrieving a service profile data- 
30 base. A protocol to be used depends on a database 

product used as a service profile database. LDAP 

(Lightweight Directory Access Protocol: stipulated by X. 

500 being the standard of ISO (Intemational Standard 

Organization) and ITU (International Telecommunlca- 
35 tlon Union)) is nonrnally used. The present invention 

does not refer to the operations of a retrieval protocol 

and a database. 

- MN (Mobile Node) 

40 

[0026] A mobile temnlnal having a Mobile IP protocol 
function. 

- CN (Correspondent Node) 

45 

[0027] A communication nodewlth which a mobile ter- 
minal communicates. 

-AAA 

so 

[0028] An acronym that is used by IETF for a server 
group that perfomis authentication, authorization, and 
accounting. The AAA server group comprises a function 
for respectively notifying an HA or an FA (Foreign Agent) 
55 of a sen/ice profile by using an HA registration request 
message or an authentication acknowledge message 
via an AAAF. 

[0029] In addition to the above described functions, 



4 



4 



EP1 124 396 A2 



8 



the AAAserver group according to the present invention 
comprises a service management function for extracting 
a service profile of a user who makes an authentication 
request from a service control database, and for gener- 
ating a service profile having a general-purpose fonnat 
in which packet control information can be set. An AAAH 
is an AAA server in a network, which holds the subscrib- 
er data of the user who makes the authentication re- 
quest, whereas an AAAF is an AAA server in a network, 
which does not hold the subscriber data of the user. The 
AAAF identifies the AAAH based on the NAI (Network 
Access Identifier) of the user, and directly transmits a 
message to the HA as a proxy. 

- FA (Foreign Agent) 

[0030] A functional entity defined by RFC 2002. An 
agent which does not have a home address assigned 
to a mobile terminal. De-encapsulaling a packet which 
Is encapsulated and transmitted to a care-of-address 
being the address of its own node, and relaying the 
packet to the link layer address corresponding to the 
home address. This address correspondence Is man- 
aged by a table called a visitor list. At the same time, 
the FA is an access router of a mobile tenninal and ari 
AAA protocol client. The FA has a session transaction 
function for managing a DIAMETER session. 

- HA (Home Agent) 

.^10031] A functional entity defined by RFC 2002. An 
agent having a home address assigned to a mobile ter- 
minal. The packet^ which is addressed to the home ad- 
dress of the mobile tenninal and relayed by the HA, is 
encapsulated and transmitted to the care-of-address of 
the FA, which con^esponds to the home address. Here, 
a "care-of-address" is something like a post offtee box 
in a nonnal postal system. This address con-espond- 
ence is managed by a table called a (mobile) binding 
cache. The HA is an AAA protocol client at the same 
time. The HA has a session transaction function for 
managing a DIAMETER session. 
[0032] Furthermore, the present invention relates to 
route optimization In the Mobile IP, and to the technique 
recited In the Japanese Patent application No 
11-276703. 

[0033] Fig. 1 explains the mobile IP. 
[0034] Assume that a network is composed of sub- 
networks 1 and 2. Also assume that a mobile node (MN) 
12 first stays in a sub-network 2, and makes a commu- 
nicatton with a CN 13 via an HA 11 . The MN 12 can be 
carried like a portable PC, and can be connected to a 
different network. 

[0035] Here, suppose that the MN 1 2 moves from the 
sub-network 2 to the sub-network 1. After the MN 12 
moves to the sub-network 1 . it attempts to start a com- 
munication with the CN 13 connected to the sub-net- 
wori<2. Initially, the MN 12 issues a registration request 



to an FA 1 0 so that the FA 1 0 makes a registration such 
that the MN 12 itsetf comes In the network 1. Further- 
more, the FA 10 notifies the HA 11 In the sub-network 2 
that the MN 12 is currently under the control of the FA 
5 1 0. The HA 1 1 issues to the CN 1 3 ah instruction to up- 
date the network binding infonmation forcommunicating 
with the MN 1 2 based on the notification from the FA 1 0. 
Upon completion of the registration for the MN 12, the 
HA 11 retums its acknowledgment to the FA 10. After 

10 the FA 10 makes a registration such that the MN 12 is 
cun-ently under its control, it retums an acknowledge 
message to the MN 12 as a notification indbating that 
a communication can be made. When transmitting a 
message to the MN 12 based on an update instruction, 

IS theCN 13 transmits a signal to the FA 10 (by tunneling)! 
and gets the FA 1 0 to transfer the message. As a result! 
a communication with the MN 12 can be enabled. 
[0036] In the meantime, In a communication from the 
MN 12 to the CN 1 3. the MN 12 first transmits the mes- 

20 sage that the MN 12 addresses to the CN 13 to the FA 
1 0. The FA 1 0 transmits the message received from the 
MN 1 2 directly to the CN 13. In this way, the MN 1 2 can 
continue to make the communication with the CN 13 
even after moving to the sub-network 1 . 

25 [0037] Fig. 2A and 2B schematically Illustrate commu- 
nication paths which are shown in and extracted from 
Fig. 1 . Fig. 2A shows the case where path optimization 
is not made, whereas Fig. 2B shows the case where 
path optimization is made. 

30 [0038] As shown in Fig. 2A, In the case where path 
optimization is not made, the message transmitted from 
the MN is transmitted to the FA. and then transmitted 
from the FA to the CN, while the message from the CN 
is once transmitted to the HA, and transmitted to the FA. 

35 The message is then transmitted to the MN. Since the 
message from the CN to the MN must pass through the 
HA as described above, the function of the HA being the 
network resource is used for each communication, lead- 
ing to a waste of network resources. 

40 [0039] Rg. 2B shows the case where path optimiza- 
tion is made. The CN having a path optimization function 
transmits the message addressed to the MN not to the 
HA but directly to the FA. which transmits the message 
to the MN. The flow of the message from the MN to the 
CN Is similar to that shown in Fig. 2A. In this way, It be- 
comes unnecessary to pass through the HA in each 
communication, thereby preventing the network re- 
sources from being wasted. 

[0040] With the function(l) being the path optimiza- 
50 tion (draft-ietf-mobileip-optim-08.bct) in the Mobile IP, 
each CN is equipped with a binding cache management 
function and a tunnel packet generation function, which 
are possessed by the HA. so that an individual CN gen- 
erates and transmits a tunnel packet addressed to the 
55 care-of-address of the MN. Consequently, the packet of 
each CN which communicates with the MN is transmit- 
ted directly to the care-of-address of the MN by means 
of tunneling and not via the HA. In this case, each CN 
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must manage protocol manipulations required for the 
path optimization, and data to be held in CN units. 
[0041] With the function (2) being the technique recit- 
ed In the Japanese Patent Application No. 11-276703, 
a "service profile" is distributed to each CN so as to per- 
fomi an Individual service control for each CN. Specifi- 
cally, a service profile is added to the binding update 
message used in path optimization, and the message 
with the profile added is transmitted to a CN. Similarly 
in the case of the above described binding cache, the 
CN newly creates an entry for a received binding cache 
if the entry does not exist within the CN itself. If the entry 
already exists, the CN updates the service profile. 
[0042] As described above, function addition is re- 
quired for each CN as its requisite so as to perfomn in- 
dividual service control. To receive the Individual sen^lce 
control recited in the Japanese Patent Application No. 
11-276703, the CN must comprise the above described 
function (2). 

[0043] Furthenmore, as a prerequisite of the CN in the 
Japanese Laid-open Patent Application No. 11-276703, 
a mobile temiinal which can receive the individual serv- 
ice control according to this application must comprise 
the processing capability of the Mobile IP. 
[0044] With this capability, however, some link layers 
cannot be supported, for example, a dial-up connection 
in PPP (Point-to-Point Protocol) being a principal proto- 
col for accessing an ISP (Internet Service Provider) in 
a mobile temninal, or the like. Forthis reason, a portable 
CN (mobile temninal) cannot receive the individual serv- 
ice control disclosed in the Japanese Patent Application 
No. 11-276703. To enable the individual service control 
to be received, the following requisites must be satisfied. 

(1) Functions must be added to a CN to be recog- 
nized as a service target according to the Japanese 
Patent Application No. 11-276703. Adding functions 
to a device with a low throughput Increases a load 
on the throughput. This does not become a problem 
in a stationary workstation or PC well within the 
maximum throughput. However, this can possibly 
become a serious problem in a portable mobile de- 
vice of a small size in some cases. 

(2) Similariy, in the technique according to the Jap- 
anese Patent Application No. 11-276703, adding 
functions to a CN is essential to receive the Individ- 
ual service control provided by Ihis technique. This 
becomes an obstacle to popularizing the service of 
this architecture. To provide every CN with the same 
service, no individual requisite must be imposed on 
a terminal. 

(3) Also in a mobile terminal which cannot use the 
Mobile IP due to a functional restriction depending 
on a link layer type when a CN connects to an ISP, 
the individual service control must be provided by 
the execution of the function on a network edge as 
a proxy. Especially, a CN which assumes a move 
between networks frequently uses a dial-up PPP, 



and cannot use the Mobile IP. This can possibly be- 
come a problem in popularizing the service in a sim- 
ilar manner as in (2). 

5 [0045] Accordingly, if the CN according to the Japa- 
nese Patent Application No. 11-276703 is attempted to 
be equipped with the above described functions, a more 
serious problem may arise, especially, In a portable CN, 
and the function specific to this architecture is required 
10 to be added. The following two requisites must be sat- 
isfied to provide the service to a wider variety of terminal 
and user types by accommodating the function of the 
CN on a network side. 

5 (1 ) Releasing each CN from being added with func- 
tions. 

(2) Also allowing a mobile terminal under a non-Mo- 
bile IP environment to receive the Individual servtoe 
control. 

0 

[0046] Fig. 3 shows the configuration of a network ac- 
cording to a preferred embodiment of the present inven- 
tion. 

[0047] In the preferred embodiment according to the 
?5 present invention, a proxy CN that acts for a CN Is ar- 
ranged in a network, not adding many functions to the 
CN as described above. The entire network is config- 
ured as a Mobile I P network, where the above described 
MN. FA, AAAF, AAAH, and HA are arranged. The FA, 
30 HA. AAAF, and AAAH can exchange messages across 
an IP transfer network 21 . The proxy CN can be imple- 
ment in software or hardware for example In a router. 
[0048] Namely, when the MN desires to communicate 
with the CN accommodated by the HA, it makes a reg- 
35 istration request to the FA. This request is notified to the 
AAAH via the AAAR The AAAH verifies the content of 
a sen/Ice to be provided by referencing a service profile 
database 22, and notifies the HA. In the above de- 
scribed explanation, the CN is connected directly to the 
40 HA, and communicates with the MN. With this method, 
however, the number of functions added to the CN in- 
creases, so that a processing delay can occur due to a 
lack of a processor processing capacity if the CN Is also 
a portable PC similar to the MN. 
45 [0049] Accordingly, a proxy CN 24 is arranged be- 
tween the CN 25 and the HA 26. The proxy CN 24 com- 
prises a functional group Including CMF, TCF, MHF, CD, 
and MAF, which will be described later. The CN 25 ac- 
cesses the proxy CN 24 in order to communicate with 
50 the MN. The proxy CN 24 inquires of a link layer authen- 
ticating server 23 as to whether or not to authenticate 
an access of the CN 25. The link layer authenticating 
server 23 obtains necessary parameters by referencing 
a service profile database 27 according to the NAI of the 
55 CN 25, verifies the content of the service to be provided 
to the CN 25. and notifies the proxy CN 24 that the com- 
munication is authorized. The proxy CN 24 issues com- 
munication authorization to the CN 25. The CN 25 that 
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receives the communication authorization transmits the 
message from the CN 25 to the IVIN via the proxy CN 24 
and the HA 26. The message transmitted to the HA 26 
is then transmitted to the MN as described above. 
[0050] By an-anging the functions to be arranged In 
the CN 25 In the proxy CN 24 as described above, there 
is no need to add functions to an individual CN. As a 
result, a CN of any type can receive a service of a cor- 
responding network. 

[0051] Furthermore, if a service provided to the CN 
25;lncludes tunneling, the message passed from the CN 
25 to the proxy CN 24 is transmitted directly to the FA. 
[0052] A service profile database 27 shown In Fig. 3 
is composed of service profiles for respective user iden- 
tifiers (NAIs). A variety of sen/lces including a security 
service, a multicast service, etc. can be registered and 
implemented. 

[0053] A sen/ice profile Is composed of NAl for Iden- 
lifylng a user, and a service block having a configuration 
which differs depending on a service type. The sen/ice 
block Is composed of a service type, policy, and infor- 
mation specific to a service. The infonmatlon specific to 
a service of packet filtering includes a regulation ad- 
dress and an application condition. The information spe- 
cific to a service of the Diff-Serv transmission applied to 
a transmission packet of a mobile tenninal includes a 
reception destination address, a reception destination 

t port, and a TOS (Type Of Service) value. The informa- 
tion specific to a sen/ice of the DIff-Serv reception ap- 

i plied to a reception packet of a mobile terminal includes 
a transmission source address, a transmission source 
port, and a TOS value. 

[00541 Here, an example of a service profile is shown 
in Fig. 4. 

[0055] The sen^ice profile is an "information set* de- 
scribing a packet controlling means required to perform 
the IP service control provided by the present invention. 
[0056] The following constituent elements are includ- 
ed as specific Items. 

(1) control target packet Infomiation 

Infonnation for identifying the type of a packet 
to be controlled. 

(2) routing/packet editing Infonnation 

infonnation about the type and the means of 
packet control (ex. transmission destination ad- 
dress, etc.) 

(3) specific control information 

Information about a service controlling means 
specific to a physical device. An FA and an HA are 
composed of a router controlling unit and a sen/Ice 
controlling unit. 

[0057] The router controlling unit comprises a routing 
table, a binding cache being a temporary routing table, 
and a service control filter for identifying a service con«^ 
trol target packet. This unit has the functions for extract- 
ing a reception IP header, and for editing header infor- 



mation. 

[0058] The service controlling unit comprises a sen/- 
ice control transaction function, with which a service 
control transaction is set, retrieved, updated, or deleted 

5 according to the request from the router controlling unit. 
The service controlling unit comprises an MIP and a DI- 
AMETER protocol function, and also comprises a gen- 
eral protocol processing function using message recep- 
tion and transmission buffers. 

10 [0059] The proxy CN functional group Is a set of func- 
tional entities required when the functions that each CN 
must comprise are separated from the CN. and ar- 
ranged on a network side. 

[0060] To be more specific, this group is composed of 
IS the functions which are listed and defined below. 

(1 ) CMF (Cache Management Function): A function 
storing and managing a binding cache (care-of-ad- 
dress, etc. of a mobile node (hereinafter abbreviat- 
ed to MN) being a communication partner) for path 
optimization In the Mobile IP. Specifically, detecting 
the binding cache transmitted from an HA, newly 
generating an entry if the entry for this cache does 
not exist, and updating the entry with the received 
information of the binding cache If the cache already 
exists. 

(2) TCP (Tunneling Capability Function): A function 
generating a tunnel packet to a care-of-address of 
the MN which implements path optimization In rela- 
tion to the above described (1). If this function Is 
comprised when a packet is attempted to be trans- 
mitted to the care-of-address of the MN which im- 
plements the path optimization, the packet is en- 
capsulated (for example, encapsulated as an IP-in- 
IP packet) based on the infonnation stored in the 
binding cache. 

(3) MHF (Message Handling Function): If a specific 
message interface Is defined in the present inven- 
tion, the MHF transmits/receives this message. If 
the proxy CN functional group is an^anged in distrib- 
uted physical entities, and If they must reciprocally 
exchange specific Information, this function gener- 
ates a message on a transmitting side or detects a 
message on a receiving side. 

(4) MAP (Mobile Agent Function): A mobile agent 
function in the Mobile IP This function is used to 
dynamically register/delele a CN that can use the 
Mobile IP to/from a proxy CN. 

(5) CD (Cache Data): Contents of the database to 
be originally possessed by a CN in the preferred 
embodiment according to the present invention. 
Having a memory for storing these contents, etc. 
Specifically, the CD is composed of a visitor list and 
a binding cache. 
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[0061] Data types that a proxy CN requires to register 
and manage an individual CN are listed below. 
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(1 ) visitor list: A list including the fundamental visitor 
inf omiation, and the information about the visit state 
flag of each CN, and the infonnation (pointer) for 
making an association with cache data to be de- 
scribed later. 

(2) binding cache: A binding cache to be continually 
held by a CN in path optimization in the Mobile IP. 
The binding cache is Included in a binding update 
message. 

(3) service profile: Profile data that is prepared for 
each NAI and for implementing the individual serv- 
ice control in the Japanese Patent Application No. 
11 -276703, The service profile is or may be Included 
in the binding update message. 



[0062] Since the arrangement of the above described 
functional entities and data configuring the proxy CN 
may differ in a network depending on an implementation 
method, there is not fixed mapping for the physical en- 
tities. In other words, there is no need to equip the proxy 
CN with all of the functions. A CN or an HA may be 
equipped with some of these functions. 
[0063] Fig. 5 shows the process for registering a CN 
(without Mobile IP functionality) to a proxy CN. 
[0064] If a CN which can move between networks 
(hereinafter refen^ed to as a mobile CN) is registered to 
a proxy CN managed by the ISP to which the CN is con- 
nected, PPP (Point-to-PoInt Protocol) is used as a gen- 
eral access method. When a connection is made to the 
ISP by a telephone line, this protocol is used In most 
cases. 

[0065] However, If the proxy CN provided by the ISP 
is attempted to be used via the PPP, the Mobile IP can- 
not be recognized. This is mainly because the mobile 
node (mobile CN) of the Mobile IP issues a registration 
request with a home address specified. However, a dial- 
up server of the PPP cannot authorize such an address 
(an address the prefix of which is different from that of 
a staying network). 

[0066] In such a case, means for using a proxy CN 
without using the Mobile IP is provided. 
[0067] For the authentication of the CN via the PPP, 
an AAA server in a Mobile IP network is unavailable. 
Therefore, a link layer authenticating server is prepared 
as a proxy of the CN using the PPP connection, and a 
connection to the network is authorized if authentication 
is made by the authenticating server. 
[0068] Furthermore, as a method for distributing the 
service profile for the CN corresponding to this case, the 
service profile database (service profile DB) connected 
to the above described link layer authenticating sen/er 
is prepared, not the AAA server, and the original data of 
the service profile for the corresponding CN is stored in 
the database. After the link layer authenticating sen/er 
receives a connection request from the CN ((1) of Fig. 
5) and verifies that this CN is a legal CN, it reads the 
profile data from the service profile DB ((2) of Fig. 5), 
and notifies the proxy CN ((3) of Fig. 5). The link layer 



authenticating server then issues access authorization 
to the CN ((4) of Fig. 5). 

[0069] In this way, the method for registering a CN to 
a proxy CN where a CN which cannot use the Mobile IP, 
5 such as a CN using the PPP is provided, thereby ena- 
bling an individual service control. 
[0070] Or, If a CN can use the Mobile I P, then the Mo- 
bile IP method can be used and implemented as the 
means for registering the CN to the proxy CN, the means 
10 being the fundamental mechanism of the Mobile IP with 
which an MN (Mobile Node) makes a registration to an 
FA (Foreign Agent). Since the proxy CN comprises an 
MAF (Mobile Agent Function), the CN is registered to 
the proxy CN with the registration procedure of the Mo- 
ts bile IP. The service profile for the CN is distributed from 
the AAA server to the proxy CN via the HA, and the pro- 
file Is stored In the service profile cache for the corre- 
sponding CN that the proxy CN manages within the 
proxy CN. 

20 [0071] Fig. 6 shows the sequence of the fundamental 
procedure for registering a CN to a proxy CN. 
[0072] The sequence shown in Fig. 6 is fundamentally 
the same as that for transmitting/receiving a message 
with the Mobile IP when the MN makes a registration to 
25 the FA, except that areas of the binding cache and the 
service profile cache of a registered CN are generated 
as a process within the proxy CN. 
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(1) The proxy CN serves also as an FA (Foreign 
Agent) of the Mobile IP Accordingly, the proxy CN 
"broadcasts" an agent advertising message that the 
FA possesses to the sub-networi< to which the proxy 
CN itself belongs. This broadcast message is re- 
ceived by all nodes within the sub-network. The 
proxy CN makes the node that attempts to register 
to the proxy CN itself receive the broadcast mes- 
sage, and notifies the node of the existence of the 
proxy CN. 

(2) The CN, which roamed to the proxy CN and Is 
cun-ently under its control, searches for the agent 
advertising message transmitted by the proxy CN. 
The CN that receives this message generates a 
registration request nnessage including the informa- 
tion of the CN itself in order to request the proxy CN 
to register the CN. 

(3) The CN transmitting the registration request 
message generated in (2). Its destination is the 
proxy CN. 

(4) The proxy CN authenticates the legality of the 
CN that transmits the registration request message. 
An authentication method depends on an imple- 
mentation of this prefen^ed embodiment. Method 
examples include a method for requesting an AAA 
server to perfomn authentication, a method with 
which the home agent of a CN perfonns authenti- 
cation, etc. When the legality of the CN is authenti- 
cated, the proxy CN perfonms the next step. 

(5) As an operation specific to the proxy CN. a serv- 
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ice profile cache and a binding cache are generated 
for a CN to be registered. 

(6) When the above described steps are property 
completed, the proxy CN transmits a registration 
acknowledge message of the Mobile IP to the CN. 
The CN that receives the acknowledge message 
leams that the registration request that the CN Itself 
transmitted is property accepted. 

[0073] Fig. 7 shows the method for managing Individ- 
ual service control data within a proxy CN. 
[0074] Here, means for holding cache data relating to 
a CN to be managed will be described. The proxy CN 
makes an association between the visitor list possessed 
by the mobile agent function of the Mobile IP and cache 
data. The visitor list includes the infomiation for individ- 
ual CNs staying In the area of the proxy CN. A specific 
association method Is as follows. Expanded Information 
is added lo each visitor list entry, and an Index pointer 
pointing to the locations of a binding cache and a service 
profile cache are stored in the expanded portion. Han- 
dling of the binding cache and the service profile cache, 
which are held by the proxy CN, can be performed to^ 
gcther with the management of tho visitor list by an MAP 
(Mobile Agent Function), so that processes such as 
cache generation, deletion, etc. can be facilitated. Here, 
the binding cache stores the care-of-address of the FA 
accessed by the MN that also makes an access to the 

V CN being a subscriber and the home address of the MN 

% by making an association between them. 

- [0075] Figs. 8 and 9 show the sequences represent- 
ing a preferred embodiment of the method for managing 
the visit state of a CN. 

[0076] A mobile CN is dynamically registered to a 
proxy CN. To detect that the mobile CN moves to a dif- 
ferent network, it is necessary to cyclically verify that 
each CN is currently under the control of the proxy CN. 
[0077] Verifying means according to this preferred 
embodiment is the one adopted in the case where the 
CN Is registered to the proxy CN by using the Mobile IP 
[0078] The CN is registered to the proxy CN using the 
registration procedure of the Mobile IP as a registering 
method. When the Mobile IP registration Is made, its life- 
time must be decided, and the CN must be re-registered 
before the lifetime expires. If the CN can use the Mobile 
IP. the above described cyclic re-registering procedure 
of the Mobile IP is also used as visit stale verification. 
[0079] Fig. 9 shows the process for a particular sub- 
scriber as a flowchart. 

[0080] In Fig. 9, the lifetime of a registration starts to 
be monitored in step SI . In step S2, the above described 
table is searched. In step S3, It is detected whether or 
not a time stamp is rewritten by the re-reglstration of the 
subscriber If the time stamp Is detected to be rewritten 
the process goes back to step 81 where the monitoring 
again starts. If the time stamp is not rewritten, the reg- 
istration of the corresponding subscriber is deleted in 
step 84. 



[0081] Figs. 1 0 through 12 show the method for man- 
agrng the visit state of a CN, according to another pre- 
ferred embodiment. 

[0082] If a CN cannot use the Mobile IP In the pre- 
5 ferred embodiment shown In Figs. 8 and 9. the cyclte 
and explicit registering methods like the Mobile IP do 
not existthen, a staying/out-of-area state cannot be ex- 
plicitly verified depending on the presence/absence of 
a registratk>n message. In this case, there is no general 
10 means for cyclically verifying the visit state. However it 
can be determined that the CN leaves the area (moves 
to a different networi< or ISP), if there is no activity of the 
CN (packet transmission) for a predetermined time pe- 
nod. The following two types are available as a verifvina 
^5 means. ^ 

[0083] Fig. 1 0 is a flowchart showing a first visit state 
managing method in the case where a CN cannot use 
the Mobile IP. 

[0084] As data being a basis, a proxy CN holds the 
20 data indicating thevlsitstate of each CN. Here, thisdata 
Is referred to as a visit state flag. 
[0085] Normally, the proxy CN monitors packets (step 

81 0) . The visit state flag is set to a "staying" state at the 
beginning of the registration of a CN or while the CN is 

25 verified to transmit packets (frequently). 

[0086] If the proxy CN detects that the packets from 
the CN do not flow for a predetermined time period (step 

811) , itconsiders that the CN has possibly left the area 
and changes the visit state flag to a pending state 

30 [0087] The proxy CN starts a determination timer at 
the same time It changes the visit state flag to the pend- 
ing state (step 812). If no packets of the CN flow before 
the timer expires (step 816), the state of the CN is de- 
termined to be "out-of-area". The visit state flag at this 

55 time is set to an "out-out-area" state (step 81 7). Once 
the "out-of-area" state Is detemnined, the proxy CN de- 
letes the registration of this CN In a similar manner as 
in the above described case where the Mobile IP is avail- 
able and the cyclic re-registration message Is not re- 

40 ceived (step S1 8). Also at this time, the corresponding 
data entry Is deleted. If the packets of the CN are de- 
tected In step 814, the state of the CN Is changed to the 
staying state in step 815. The process then goes back 
to step SI 0 Where the proxy CN restarts to monitor pack- 

45 ets. 

[0088] Fig. 12 shows the state transition of the visit 
state nag In the method shown in Fig. 10. 
[0089] The visit state flag that is initially set to the stay- 
ing state makes a transition to the pending state when 

50 no packets are detected to flow. Here, if packets are 
again detected to flow, the visit state flag is restored to 
the staying state. However, if no packets are again de- 
tected to flow in the pending state, the CN is detennined 
to be out of the area of the proxy CN. Therefore, the visit 

55 state flag is changed to the out-of-area state. The visit 
state flag of a newly registered CN is first set to the stay- 
ing state after its data entry is generated. Thereafter the 
above-described transition is repeated until the CN gets 
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out of the area. 

[0090] Fig. 11 is a flowchart showing a second visit 
state managing method in the case where a CN cannot 
use the Mobile IP. 

[0091] For each CN that a proxy CN manages, a " pre- 
ceding visit state verification time" (hereinafter referred 
to as a verification time stamp) is added as expanded 
data of a visitor list entry. Furthemnore, a single cyclic 
monitoring task (hereinafter referred to as a monitoring 
task) in the entire proxy Is started. 
[0092] This monitoring task references the verification 
time stamps of all of staying CNs in a predetermined 
cycle. A verification time stamp is a time at which the 
packet transmitted from the CN is detected in the pre- 
ceding cycle. 

[0093] If the difference between the current time and 
the verification stamp is larger than the value stipulated 
within the proxy CN, that Is. it no packets from the CN 
are detected to flow for a predetermined lime period or 
longer, the registration of the CN Is deleted. If the differ- 
ence is smaller than the stipulated value, the CN is de- 
termined to stay, and the proxy CN continues to hold the 
registered state. 

[0094] That is , in Fig . 1 1 , visit state verification is start- 
ed In step S20, and the monitoring task starts the proc- 
ess. First of all, in step S21, an n-th CN entry is 
searched. In step S22, the comparison between the cur- 
rent time and the preceding packet detection time of the 
CN is made. At this time, the detection time is obtained 
by reading the verification time stamp. Then. In step 
S23, it is determined whether or not the time difference 
obtained as a result of the comparison is smaller than a 
stipulated value. If the time difference is smaller than the 
stipulated value, the most recent packet is attempted to 
be detected in step S24. If the packet is detected, its 
time is registered as a verif Nation time stamp. If the time 
difference is largerthanthe stipulated value in step S23, 
the registration of the CN is deleted. The monitoring task 
performs the steps S21 through S25 forall of CN entries. 
When the completion of one monitoring cycle is verified 
in step S26, the process goes to step S20 where the 
visit state verification process is restarted. 
[0095] Furthermore, as another method for managing 
the visit state of a CN. the following method may be con- 
sidered. 

[0096] Sometimes, a CN that cannot use the Mobile 
IP may disconnect a link to a proxy CN by explicitly dis- 
connecting a telephone line, etc. This disconnection can 
be detected as a line disconnection of a link layer on a 
proxy CN side (network side). The proxy CN monitors 
the information about this link layer disconnection. 
When the proxy CN detects the disconnection. It deter- 
mines that the CN has left the area, and perfomis the 
process for deleting the registration of the CN. 
[0097] A specifte method for detecting the disconnec- 
tion between the proxy CN and the CN as a line discon- 
nection of a link layer can be easily understood by a per- 
son having ordinary skill in the art. Accordingly, the de- 



termination of whether or not the CN leaves an area, 
and the registration deletion process based on this de- 
termination are considered to be easily Implemented by 
the person having ordinary skill in the art. 
5 [0098] Rg. 1 3 shows a first prefenred embodiment of 
the method for arranging the proxy CN functional group. 
[0099] As the method for arranging the proxy CN func- 
tional group, a binding update message transmitted 
from an HA to a CN is recognized by a proxy CN. which 
) 0 pert omns an actual message process as a proxy of a CN . 
[01 00] With this arrangement method, all of the func- 
tional entities such as CMF. TCP, MHF. MAF. and CD 
are accommodated in an adjacent router (proxy CN: set 
as a default router that the CN nomially accesses). 
15 Therefore, a dedicated external interface for linking the 
functions is not required when being equipped. The 
binding update message transmitted to the CN passes 
through the proxy CN that serves also as a default rout- 
er. However, the MHF (Message Handling Function) 
so within the proxy CN functional group has a function for 
searching for the header infomnatlon of all packets, and 
monitors a Mobile IP control message. 
[01 01 ] A detected binding update message is passed 
to the CMF (Cache Management Function) of the proxy 
25 CN, and reflected on the CD (Cache Data) of the CN. 
[0102] The Mobile IP control message is detected as 
follows. The "Protocol" field of an IP header is refer- 
enced, and the packet which satisfies the following two 
conditions (1 ) and (2) is detennined as a "Mobile IPcon- 
30 trol message": (1 ) the "Protocol" field indicates the TCP 
(Transmission Control Protocol) or the UDP (user Dat- 
agram Protocol); and (2) The "port number" field in the 
TCP/UDP header is referenced, and this field indicates 
a Mobile IP control message. A packet which does not 
35 satisfy these conditions is a data packet. Next, it is de- 
temnined whether or not the packet which satisfies the 
above conditions Is a binding cache management mes- 
sage. Specifically, the "Type" field of the Mobile IP head- 
er is referenced (e.g. Type: binding update message). 
40 If the packet is detennined to be the binding cache man- 
agement message, the proxy CN identifies the CN being 
the (original) destination of this message from the "Des- 
tination" field of the IP header. By using the infomnatlon 
for Identifying the CN in the above condition as a key, 
45 the proxy CN operates the binding cache entry (updates 
the binding cache) of the CN. 

[01 03] Fig. 1 4 shows a second preferred embodiment 
of the method for arranging the proxy CN functional 
group. 

50 [0104] If the process for detecting a binding update 
message imposes a heavy load on the proxy CN as the 
method for arranging the proxy CN functional group, 
part of the function of the MHF is arranged in the HA. 
That is, the function for rewriting the destination of the 
55 binding update message from a default CN to a proxy 
CN in the HA being the transmission source of the bind- 
ing update message is arranged. 
[0105] Namely, the first binding update message is 
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transferred to the proxy CN unchanged. The proxy CN 
terminates the first binding update nnessage that is orig- 
inally addressed to the CN. and updates the binding 
cache. Next, the proxy CN transmits a binding acl<nowl-. 
edge message to the HA. With this message, the HA is 
requested to rewrite and transfer to a proxy CN the des- 
tination of the binding update message transmitted, 
which is caused by the movement of an IVIN. The HA 
transmits the second and the subsequent binding up- 
date messages to the proxy CN as requested. 
[0106] As a result, the proxy CN no longer needs to 
perfomi the message detection process for the second 
and subsequent binding update messages, thereby re- 
ducing the load on the proxy CN. 
[0107] Fig. 15 shows a third prefen-ed embodiment of 
the method for arranging the proxy CN functional group. 
[0108] With this method for an^anging the proxy CN 
functional group, the IS/IHF Is anranged In a CN. and the 
olherfuncllons in addition lo the MHF are arranged with- 
in a proxy CN. A binding update message is once trans- 
mitted to the CN in a similar manner as in the technique 
disclosed by the application that was previously filed by 
this applicant. Here, the CN comprises the function for 
detecting the binding update message, and transferring 
the message to the proxy CN to which the CN is reqis- 
tered. 

[01 09] As a result, only binding update messages are 
? transmitted from the CN to the proxy CN. Therefore, the 
^ proxy CN no longer need to examine all of messages 
: passing through the proxy CN itself, and to determine 
^whether or not each of the passing messages Is an up- 
dated binding message, whereby also the message 
process load on the proxy CN itself is reduced. 
[01 1 0] Data packets other than a Mobile I P message 
packet, which are transmitted from the CN, are received 
by the proxy CN serving also as a default router, and the 
proxy CN alternatively performs the operations of the 
CN. Namely, the proxy CN detennines whether or not 
path optimization can be applied to the CN being the 
transmission source of the packets, performs the serv- 
ice control corresponding to the CN if the CN is a termi- 
nal to which the path optimization can be applied, gen- 
erates a tunneling packet with the TCP, and transmits 
the generated packet. 

[011 1 ] The procedures for registering a CN to a proxy 
CN are summarized below. 

- Registration of the CN which can use the IVIobile IP 



(1) The proxy CN broadcasts the above de- so 
scribed agent advertisement of the Mobile IP to 

the entire network to which the proxy CN be- 
longs. 

(2) The CN equipped with the Mobile IP function 
receives the above described advertisement of 55 
the proxy CN, and transmits a Mobile IP regis- 
tration request message to the proxy CN. 

(3) The proxy CN verifies the legality of the CN 



according to the authentication made by an 
AAA server. 

(4) Upon completion of the authentication, the 
proxy CN generates an entry of the cache data 
(a binding cache and a service profile) for the 
CN. 

(5) When the registration process within the 
proxy CN normally terminates, registration ac- 
knowledgment is returned to the CN by using a 
Mobile IP registration reply message. 

Registration of the CN which does not use the Mo- 
bile IP 

(1) The CN which does not use the Mobile IP 
attempts to make a connection to an ISP with 
the dial-up PPP. 

(2) The dial-up server which receives the con- 
nection request from the CN requests the au- 
thenticating server relating to the dial-up server 
to authenticate the legality of the CN. For the 
authentication method using a PPP connec- 
tion, PAP (Password Authentication Protocol) 
or CHAP (Challenge-Handshake Authentica- 
tion Protocol) is used. 

(3) The authenticating server which receives 
the authentication request reads the service 
profile of the CN from the service profile DB (da- 
tabase) storing the service profile of the CN, 
when the legality of the CN is verified. 

(4) The authenticating server transmits the 
service profile of the CN. which is obtained in 
the above described step (3), to the proxy CN 
to which the CN is requested to be registered. 

(5) The proxy CN generates a visitor list entry 
for the CN based on the profile transmitted in 
the step (4), and also generates an entry for 
storing this entry, the binding cache relating to 
path optimization, and the service profile noti- 
fied from the authenticating server 

(6) The authenticating server retums registra- 
tion acknowledgment to the CN that issues the 
registration request. 



^5 [0112] The procedures for verifying the visit state of a 
CN are summarized below. 



Verification of the visit state of the CN which can 
use the Mobile IP 

(1) A mobile CN must repeatedly make a re- 
registration in a cycle shorter than the registra- 
tion lifetime that the proxy CN and the mobile 
CN Itself agree upon as the function of the Mo- 
bile IP, and transmits the Mobile IP registration 
request message to the proxy CN to which the 
mobile CN is currently being registered. 

(2) The proxy CN detenmines that this mobile 
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CN is staying in its area upon receiving the 
above described re-registration request. 
(3) If the proxy CN does not receive the re-reg- 
istration request before the registration lifetime 
expires, the registration of the CN is deleted 
with the Mobile IP procedure. Specifically, the 
visitor list entry for this CN is deleted within the 
range of the Mobile IP function. At the same 
time, the binding cache and the service profile, 
which are associated with this visitor list entry, 
are deleted. Namely, the data regarding the 
proxy CN function are deleted simultaneously 
with the registration deletion procedure of the 
Mobile IP. 

Verification of the visit state of the CN which cannot 
use the Mobile IP 



Method 1 



[0113] 



(1) The proxy CN monitors the flow of the packets 
transmitted from the CN. The proxy CN uses part 
of a visitor list entry, and registers the visit state for 
each CN. When the CN is transmitting packets dur- 
ing the registration, its state is recognized to be a 
staying state. 

(2) If no packets transmitted from the CN are de- 
tected to flow for a predetennined time period dur- 
ing the above described monitoring operation, the 
proxy CN considers that the CN has possibly left 
the area, and sets the visit state of the CN to a pend- 
ing state. 

(3) If no packets from the CN are detected to be 
transmitted for another predetemnined time period 
in the above described pending state, the proxy CN 
determines that the CN got out of the area. 

(4) If the packets from the CN are detected during 
the packet monitoring time period in the above de- 
scribed step (3), the visit state is restored to the 
staying state. 

Method 2 



(3) If the time difference is smaller than the stipulat- 
ed value, the CN Is detemnined to stay in the area, 
and its packets are attempted to be detected. If the 
packets are detected as a result, the verification 

5 time stamp is updated to the latest packet detection 
time. If the packets are not detected, the verification 
time stamp Is not updated. 

(4) These steps (1) through (4) are repeated in the 
cycle stipulated by the proxy CN system, so that cy- 

10 die visit state verification can be implemented. 

- Line disconnection of a link layer if the Mobile IP is 
unavailable 

15 [0115] 

(1 ) A CN is assumed to be connected to an access 
server with the PPP. 

(2) Upon completion of the communication by the 
20 CN, the line disconnection message of the link layer 

is transmitted to an access server. 

(3) The access server that detects the line discon- 
nection message notifies the MHF of the proxy CN 
functional group of the line disconnection by the CN. 

2S (4) The MHF of the proxy CN functional group trans- 
mits the message indicating that the CN left the area 
to the MAP. 

(5) The MAP deletes the visitor list entry for the CN. 
and at the same time, it requests the CMP to delete 
30 the binding cache and the service profile for this CN. 
Here, the registration deletion of the CN is complet- 
ed. 



[0114] 



(1) The cycle monitoring task running within the 
proxy CN searches for the preceding packet trans- 
mission verification time (verification time stamp) 
for ail of the CNs under its management. 

(2) The cycle monitoring task obtains for each CN 
the difference between the verification time stamp 
and the current time. If this time difference is larger 
than the value stipulated within the proxy CN, the 
CN is determined to have not transmitted packets 
for a predetermined time period or longer, and its 
registration Is deleted. 



[0116] Figs. 16 and 17 are flowcharts explaining the 
35 IP service control message process in the preferred em- 
bodiment shown in Fig. 13. Fig. 16 shows the case 
where a cache area Is generated upon completion of the 
registration of a CN to a proxy CN, whereas Fig. 17 
shows the case where a cache area is generated when 
40 the first binding update message of the CN reaches the 
proxy CN. 

[0117] In Fig. 16, if there is a cache of the tennlnal 
(CN) to be targeted as a sen^ice profile which is added 
to a binding update message, the cache is only updated. 

45 However, if no cache area exists due to some cause or 
another (a lack of resource, etc.), an abnormal se- 
quence is adopted. In this case, the proxy CN can notify 
the HA being the transmission source that the received 
cache was not properly processed. A "binding acknowl- 

50 edge" message, which is defined by the Mobile IP ex- 
pansion protocol (path optimization), is used as this no- 
tification. 

[01 18] Therefore, if a cache cannot be generated, the 
proxy CN generates the binding acknowledge message, 
55 stores the value indicating that the cache was not prop- 
erly processed by the proxy CN itself being the reception 
destination, and transmits the message to the HA. 
[0119] In Fig. 16, the HAfirst transmits the binding up- 
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date message (Including a profile cache) to the CN to 
be path-optimized. The binding update message reach- 
es the proxy CN which serves also as a default router 
for the destination CN. The proxy CN waits for a packet 
in step S30, and detects the reception of the packet in 
step S31 , searches for each header of all of the received 
packets (regardless of their data and Mobile IP control 
message), and detemnines whether or not each packet 
is a binding update message addressed to the CN (step 
S32). A method for detemrilning whether or not a packet 
Is a binding update message is as follows. Namely, the 
packet which satisfies the following two conditions is de- 
temilned to be a Mobile I P control message by referenc- 
ing the "Protocol field" of an IP header: (1 ) the "Protocol" 
field indicates either TCP or UDP; and (2) the "Port 
number" field within the TCP/UDP header indicates a 
mobile I P control message. If a received packet is a data 
packet, a different packet process is performed In step 

533, and control is then returned lo step S30. 

[01 20] If the packet is determined to be a binding up- 
date message in step S32, it is further determined 
whether or not the binding update message packet is a 
binding cache management message for path optimiza- 
tion by examining the con^osponding packet field. Spe- 
cifically, the 'Type" field in the Mobile IP header is ref- 
erenced (e.g. "Type" is a binding update message). If 
the packet is determined to be a binding cache manage- 
, ment message, the proxy CN identifies the CN being the 
(original) destination of this message from the "Destina- 
V tion" field in the IP header. For the packet which Is de- 
,5 Jennlned to be the binding update message, it is deter- 
mined whether or not the cache corresponding to the 
destination CN exists in step S34. If the con-esponding 
cache exists, it is stored in the binding cache and the 
servtee profile cache, which are held by the proxy cache, 
and it Is also operated by the proxy CN functional group! 
The proxy CN then perfomns the operations and func- 
tions, which are requested of the CN being the original 
destination. If no con^esponding cache exists in step 

534. a binding acknowledge message indicating "not a 
servtee control target" is generated in step S36. The 
generated message is then transmitted in step S37, and 
control is returned to step S30. 

[0121] Fig. 17 is a flowchart showing the packet proc- 
ess performed in the case where a cache area is gen- 
erated In the proxy CN when the first binding update 
message from a CN reaches Ihe proxy CN. 
[0122] In this flow, the process which is performed 
when no corresponding cache exists is different. Name- 
ly, upon receipt of the first binding update message (plus 
the sen/ice profile cache) for the CN, a cache area is 
newly generated, and the data of the sen/ice profile 
cache is stored in this area. 

[01 23] First of all , in step S40, the proxy CN waits for 
a packet. Then, the proxy CN detects the reception of 
the packet in step S41 , and detemnines whether or not 
the received packet is a binding update message in step 
S42. If the packet is detennined not to be the binding 



update message, the proxy CN perfomis the different 
process in step S43. If the packet is determined to be 
the binding update message, the process goes to step 
S44. 

5 [0124] The proxy CN detennines whether or not the 
binding cache (or just cache) corresponding to the CN 
being the message destination exists in step S44. If the 
con-esponding binding cache exists, the proxy CN up- 
dates the cache. If the con-esponding cache does not 

10 exist, the proxy CN generates a cache. The process 
then goes back to step S40. 

[0125] Rgs, 18 through 21 are flowcharts showing the 
IP service control message process in the preferred em- 
bodiment shown in Fig. 14. Fig. 18 shows the case 

IS where a cache area is generated upon completion of the 
registration of a CN to a proxy CN, whereas Fig. 19 
shows the case where a cache area Is generated when 
the first binding update message of the CN reaches the 
proxy CN. Fig. 20 summarizes the packet process per- 

20 formed by each functional entity, and shows the recep- 
tion detennlnation process by the HA. Fig. 21 summa- 
rizes the packet process performed by each functional 
entity, and shows the transmission process determina- 
tion made by the HA. 

25 [0126] First of alt. the HA transmits the first binding 
update message to the HA as a destination. The proxy 
CN waits for a packet In step S50, and detects the re- 
ception of a packet in step S51 . The proxy CN then de- 
tennines whether or not the received packet is a binding 

30 update message in step S52. If the packet is not the 
binding update message, the proxy CN performs a dif- 
ferent packet process in step S53. and control is re- 
turned to step S50. If the received packet is determined 
to be the binding update message in step S52, the proxy 

35 CN being the default router of the CN examines the des- 
tination of the binding update message. If the destina- 
tion is the proxy CN, the proxy CN determines whether 
or not a target cache exists in step S58. If the target 
cache exists, the proxy CN updates the cache in step 

^0 S59. If the target cache does not exist, the proxy CN 
generates a binding acknowledge message in step S60, 
and transmits this message in step S61 . Then, control 
is returned to step S50. 

[0127] If the destination of the binding update mes- 
^5 sage is the CN in step S54, the proxy CN generates and 
holds the binding cache and the service profile cache 
(step S55), which are included in the message, without 
transmitting this binding update message to the CN be- 
ing the original destination. Then, the MHF within the 
50 proxy CN returns the binding update acknowledge mes- 
sage to the HA being the transmission source of the 
binding update message as a specific message (steps 
S56 and S57). This message declares that the proxy CN 
processes binding update messages which are trans- 
55 mitted thereafter as a proxy of the CN, 

[0128] If the default router does not comprise the 
proxy CN functions, the binding update message is 
transmitted to the CN. and the CN itself processes the 
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binding update message. 

[0129] The HA that receives the binding update ac- 
knowledge message associates the proxy CN being the 
transmission source with the infomnation of the CN 
which is the original destination and is under the control 5 
of the proxy CN, changes to the proxy CN the destina- 
tion of the second and the subsequent binding update 
messages transmitted to the CN, and transmits the mes- 
sages. Accordingly, the proxy CN receives and process- 
es the second and the subsequent binding update mes- 
sages relating to the CN. 

[01301 Fig. 19 shows the process performed by a 
proxy CN in the case where a cache area Is generated 
when the first binding update message of a CN reaches 
the proxy CN. 

[0131] First of all, in step S70, the proxy CN waits for 
a packet. In step S71 , the proxy CN detects the recep- 
tion of the packet. The proxy CN then detemr\ines wheth- 
er or not the received packet is a binding update mes- 
sage in step S72. If the received packet Is not the binding ^ 
update message, the proxy CN perfonms a different 
packet process in step S73. Control is then retumed to 
step S70. 

[0132] If the received packet is detennined to be the 
binding update message In step S72, the proxy CN ex- - 
amines the destination of this message. If the destina- 
tion is the proxy CN, the proxy CN further determines 
whether or not a cache to be updated exists in step S78. 
If the cache to be updated exists, the proxy CN updates 
the cache in step S79. If the conresponding cache does 
not exist, the proxy CN generates a cache. 
[0133] If the destination of the binding update mes- 
sage is the CN in step S74, the proxy CN generates a 
cache area, further generates a binding update ac- 
knowledge message, and transmits the generated mes- 
sage to the HA (steps S76 and S77). 
[0134] Fig. 20 summarizes the packet process per- 
formed by each functional entity in the pref en^ed embod- 
iment shown in Fig. 14, and is a flowchart showing the 
reception process determination made by an HA. 
[0135] The HA waits for a packet in step S85. When 
the packet is transmitted, the HA detects the reception 
of the packet in step S86. In step S87, the HA deter- 
mines whether or not the received packet is a binding 
update acknowledge message. If the received packet is 
not the binding update acknowledge message, control 
is returned lo step S85 where the HA will wall for the 
next packet. If the received packet is detennined to be 
the binding update acknowledge message in step S87, 
the HA changes the destination of the binding update 
message within the infomnation entity for the con-e- 
sponding CN. Control is then returned to step S85 where 
the HA will wait for the subsequent packet. 
[0136] Fig, 21 summarizes the packet process per- 
formed by each functional entity in the pref en-ed embod- 
iment shown in Fig. 14, and is a flowchart showing the 
transmission process determination by the HA. 
[0137] First of ail, in step S90. the HA completes the 



preparation for a packet transmission. The HA analyzes 
the packet type In step S91 , and detemrilnes whether or 
not a received packet is a binding update message In 
step S92. If the received packet is not the binding update 
message, the HA perfonns the packet transmission 
process In step S96 (the process for transmitting a pack- 
et to its destination). Control Is then returned to step 
S90. If the received packet is detenmined to be the bind- 
ing update message in step S92, the HA examines 
' whether or not the destination of the transmission pack- 
et is changed according to binding update acknowledg- 
ment (step S93), and detenmlnes whether or notthe des- 
tination of the binding update message must be 
changed in step S94. If the HA detemnines that there Is 
5 no need to change the destination in step S94, the HA 
transmits the packet to the destination of the received 
packet in step S96. If the HA detemiines that the desti- 
nation must be changed in step S94, It changes the des- 
tination of the packet in step S95, and transmits the 
0 packet to the changed destination (proxy CN) in step 
S96. Upon completion of the packet transmission proc- 
ess, control Is retumed to step S90 and this process Is 
repeated. 

[01 38] Figs. 22 through 24 are flowcharts showing the 
?5 IP service control message process in the preferred em- 
bodiment shown in Fig. 15. Fig. 22 shows the case 
where a cache area Is generated upon completion of the 
registration of a CN to a proxy CN. whereas Fig, 23 
shows the case where a cache area is generated when 
30 the first binding update message of the CN reaches the 
proxy CN . Fig. 24 is a flowchart showing the determina- 
tion process performed by the CN among the summa- 
rized packet processes of the respective functional en- 
tities. 

35 [0139] In Fig. 22 the HA first transmits a binding up- 
date message to the CN as a destination. The proxy CN 
being the default router of the CN receives this message 
(step S1 01 ) while it is in a packet wait state (step SI 00). 
The HA then detemnines whether or not the received 
40 message is a binding update message, and whether or 
not to transfer this message to the CN (step SI 02). If 
this message is detenmined to be a message to be trans- 
ferred, the proxy CN transfers the message to the CN 
similar to a nonnal router. Control is then retumed to 
45 step SI 00. 

[0140] If the proxy CN detemiines that the message 
is the binding update transfer message, thai Is, the mes- 
sage addressed to the proxy CN itself in step SI 02. it 
further determines whether or not the cache corre- 
50 spending to the CN exists in step S103. If the corre- 
sponding cache exists, the cache entry is updated in 
step SI 04. Control is then returned to step S100. If the 
con-esponding cache is detemnined not to exist in step 
SI 03, a binding acknowledgment message is generat- 
55 ed in step SI 05. In step SI 06, the CN detects that the 
packet which is transmitted and received from the proxy 
CN Is the binding update message. Here, the CN which 
detects the binding update message structure of a blnd- 
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ing update transfer message as Its specific message, 
and transmits the structured message to the proxy Cfsi 
to which the CN itself Is registered. This message In- 
cludes the Information that the proxy CN can recognize 
to be a binding update message as header information, s 
and binding cache data and service profile data, which 
are included in the binding update message, as payload 
information. The proxy CN that receives the binding up- 
date transfer message transmitted from the CN under 
its control, verifies that this message is a binding update io 
transfer message based on the header infomiation. The 
proxy CN registers the data for this CN, which Is Includ- 
ed in the verified message. 

[01 41 ] Fig. 23 is a flowchart showing the process per- 
formed by a proxy CN in the case where a cache area is 
is generated when the first binding update message 
reaches the proxy CN. 

[01 42] First of all, in step S1 1 0, the proxy CN waits for 
a packet. When the proxy CN detects the reception of 
the packet in step S11 1 , It detemriines whether or not the 20 
received packet is a binding update message, and 
whether or not the message is to be transferred to the 
CN in step S112. If the message is determined not to be 
transferred to the CN, control Is returned to step S110. 
Then, this process is repeated. 25 
[0143] If the received packet Is detennined to be a 
binding update transfer message in step S1 1 2, the proxy 
CN further determines whether or not this message Is 
> the first binding update transfer message to the CN in 
•step S113. If the message is the first binding update 30 
-..trafisfer message, the proxy CN generates a cache en- 
try in step S115. Control is then returned to step S11 0. 
If the message is not the first binding update transfer 
message in step S1 13, the proxy CN updates the cor- 
responding cache entry in step S114. Then, control Is 3s 
returned to step S110. 

[0144J Fig. 24 is a flowchart showing the determina- 
tion process performed by the CN. 
[0145] First of all. in step S120, the CN waits for a 
packet In step S120. Upon receiving the packet in step 40 
S121, the CN determines whether or not the received 
packet is a binding update message in step S122. If the 
packet is not the binding update message, control Is re- 
turned to step SI 20 where the CN again waits for a 
packet. If the received packet is detennined to be the 45 
binding update message in step S122, the CN gener- 
ates a binding update transfer message in step SI 23, 
and transmits the generated message to the proxy CN 
in step 8124. Control Is then returned to step Si 20. 
[0146] The process for a data packet which is not a so 
binding update message is explained below. 



con^esponding entry. 

(4) Whether or not the CN Is a path optimization tar- 
get is made according to the visitor list entry of the 
CN being the transmission source. 

(5) If the packet transmitted from the CN Is deter- 
mined to be a path optimization target, the proxy CN 
passes control to the TCF (Tunneling Capability 
Function), and requests the TCF to generate a tun- 
neling packet. 

(6) The TCP generates a tunneling packet, passes 
the data and control of the packet to a router func- 
tion unit within the proxy CN, and requests the unit 
to transmit this packet. 

(7) The router function unit within the proxy CN 
transmits the generated tunneling packet. 

[01 47] As described above, the present invention was 
explained based on the particular preferred embodl- 
menl. However, the present invention is not limited lo 
the above described preferred embodiment, and covers 
various modifications made by a person having ordinary 
skill in the art. 

[0148] Especially, the arrangement of the above de- 
scribed functions such as CMF, TCF, MHF, CD. and 
MAF is not limited to the above described preferred em- 
bodiment. The functions may suffice to be arranged in 
any locations on a networi< side to which a CN is con- 
nected. 

[0149] According to the present invention, the func- 
tional group which is forced to be arranged In a corre- 
spondent tennlnal (CN) conventionally Is concentrated 
on a networic side, whereby equivalent functions can be 
provided without adding functions to the CN (or by mak- 
ing a minimum addition). 

[0150] Accordingly, even a portable terminal with a 
low throughput can use an Individual service control 
without concern about a functional addition and an in- 
crease in a processing load. 

[0151] Furthermore, according to the present inven- 
tion, the function for accepting the registration of a CN 
with a link layer, which cannot use a particular protocol, 
Is prepared as a method for registering a CN to an ad- 
jacent router (proxy CN) equipped with the functional 
group concentrated on a networi< side In addition to a 
method using the registration mechanism of the partic- 
ular protocol, thereby securing the Independence from 
the link layer. 

[0152] Accordingly, registration to a proxy CN and use 
of an individual service control can be implemented 
even with various link layers. 



(1 ) A CN under the control of a proxy CN transmits Claims 
the data packet lo a particular MN. 

(2) The above described data packet reaches the ss 1. 
proxy CN which sen/es also as a default router. 

(3) The proxy CN identifies the transmission source 
of this data packet, and searches a visitor list forthe 



A mobile communications system composed of a 
plurality of sub-networks and for enabling a corre- 
spondent tenmlnal (25) to communicate with a mo- 
bile temilnal (12), the mobile temiinal (12) may 
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move from one sub-network (1 )to another sub-net- 
work (2), characterized by: 

an authentication unit (23) for authenticating 9. 
said correspondent temninal (25); ^ 
a setting unit for setting comnnunication parann- 
eters that the correspondent temiinal (25) re- 
quires to communfcate with the mobile temninal 
(12) and updating the communication paranne- 
ters when the mobile tenminal (1 2) moves from 
a first sub-network (1 ) to a second sub-network 
(2); and 

a communicating unit for communicating be- 10. 
tween network controlling devices in order to 
set the communication parameters. 

2. The mobile communications system according to 
claim 1 , further characterized in that a Mobile IP is 
adopted as a communication protocol. 
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The mobile communications system according to 11. 
claim 2, further characterized in that said con-e- 
spondent temninal (25) does not support the Mobile 
IP protocol. 



25 



The mobile communications system according to 
claim 2, further characterized by: 

a tunneling unit for editing a data packet re- 
ceived from said correspondent temninal (25) and 
destined for the mobile temninal (1 2) and for trans- 30 
mitting the edited data, packet directly to the first 
sub-network (1) when said con-espondent temninal 
(25) exists in the first sub-network (1) and the mo- 
bile terminal (12) exists in the second sub-network 
(2). 



35 



5. The mobile communications system according to 
claim 1, further characterized in that said con^e- 
spondent temninal (25) is a temninal which can move 
from one sub-network (1) to another sub-network 
(2). 

6. The mobile communications system according to 
claim 1, further characterized by: 

a router (24) coupled to said con^espondent 
tenninal (25), wherein said setting unit and said 
communicating unit are arranged in said router (24). 

7. The mobile communications system according to 
claim 2, further characterized by: 

visit state verifying means for detemnining 
whether or not said correspondent terminal (25) ex- 
ists in a predetermined area. 

8. The mobile communications system according to 
claim 7, further characterized in that 

if said correspondent temninal (25) does not 
exist in the predetemnined area, the communication 



parameters for said correspondent temninal (25) are 
deleted. 

The mobile communteations system according to 
claim 2. further characterized In that 

if said coaespondent temninal (25) is a Mobile 
IP correspondent temninal (25), said correspondent 
terminal (25) is determined to have left a predeter- 
mined area when the correspondent temninal (25) 
does not make a registration in the predetermined 
area. 

, The mobile communications system according to 
claim 7, further characterized in that 

said visit state verifying means detemnines 
that said con-espondent terminal (25) no longer ex- 
ists in the predetemnined area by detecting that 
packets relating to said correspondent temninal (25) 
are not transmitted and received. 

. A mobile communications method for enabling a 
con-espondent tenninal (25) to communicate with a 
mobile temninal (12) in a network composed of a 
plurality of sub-networks having network controlling 
devices, and for continuing to communicate even 
when the mobile terminal (1 2) moves from one sub- 
network (1) to another sub-network (2), character- 
ized by: 

authenticating the correspondent tenninal (25); 
setting communication parameters that the cor- 
respondent temninal (25) requires to communi- 
cate with the mobile temninal (12); 
updating the communication parameters when 
the mobile tenninal (1 2) moves from a first sub- 
network (1) to a second sub-network (2); and 
communicating the communication parameters 
between the network controlling devices in or- 
der to set the communication parameters. 

12. The mobile communications method according to 
claim 11. further characterized in that a Mobile IP 
protocol is adopted as a communication protocol in 
the mobile communications method. 

13. The mobile communications method according to 
claim 12, further characterized in that the corre- 
spondent temninal (25) does not support the Mobile 
IP protocol. 

14. The mobile communications method according to 
claim 12, further characterized by: 

editing a data packet received from the corre- 
spondent tenninal (25) anddestinedforthe mo- 
bile temninal (12); and 

transmitting the edited data packet directly to 
the second sub-network (2), and making the 
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data packet reach the mobile terminal (12). 
when the correspondent terminal (25) exists in 
the first sub-networl< (1) and the mobile termi- 
nal (12) exists in the second sub-networl< (2). 

The mobile communications method according to 
claim 11, further characterized in that the corre- 
spondent terminal (25) is a temilnal which can move 
among the plurality of sub-networks. 

The mobile communications method according to 
claim 11, further characterized in that the setting 
and communicating steps are perfomried in a router 
(24) coupled to the correspondent terminal (25). 

17. The mobile communications method according to 
claim 12, further characterized by: 

determining whether or not the correspondent 
terminal (25) exists In a predetermined area, where- 
in the predetenmined area is an area where the cor- 
respondent terminal (25) may access the network. 

18. The mobile communications method according to 
claim 17, further characterized In that 

if the correspondentterminal (25) does not ex- 
ist In the predetermined area, the communication 
parameters for the correspondent tenninal (25) are 
deleted. 

:. 19. The mobile communteations method according to 
i claim 12, further characterized in that 

if the correspondent terminal (25) is a Mobile 
IPcon'espondenttenTiinal(25),detemniningthatthe 
correspondent tenninal (25) has left a predeter- 
mined area when the correspondent temninal (25) 
does not make a registration to the predetermined 
area. 

20. The mobile communications method according to 
claim 17. further characterized in that 

the visit state verifying step determines that 
the con-espondent terminal (25) no longer exists in 
the predetennined area by detecting that packets 
are not transmitted and received by the con-espond- 
ent temninal (25). 
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22 



10 



The method of claim 21 . further characterized by: 

tunneling the data packet from the corre- 
spondent temiinal (25) to the mobile terminal (12) 
based on the binding information, the binding infor- 
mation being Information which provides a corre- 
spondence between an IP address of the mobile 
terminal (12) and an IP address of a foreign agent 
(10) that is accommodating the mobile terminal 
(12). 
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21. In a proxy correspondenl node (24), a method of 
providing a communication sen/Ice to a correspond- 
ent terminal (25) that communicates with a mobile 
tenminal (1 2), characterized by: so 

hunting binding information about the mobile 
terminal (12), the binding information being 
transferred from a home agent (26) of the mo- 
bile temninal (12) to the correspondent tenninal ss 
(25). and 

processing a data packet from the correspond- 
ent tenninal (25) to the mobile tenninal (12) 



23. A mobile communications method for registering a 
con-espondent tenninal (25) and enabling the cor- 
respondent terminal (25) to communicate with a 
mobile temninal (12) in a networtc composed of a 
plurality of sub-networt<s and for continuing to com- 
municate even when the mobile tenninal (12) 
moves from one sub-networi^ (1) to another sub- 
networic (2), characterized by: 

receiving a connection request from the corre- 
spondent temninal (25); 

authenticating the correspondent tenninal (25); 
retrieving a service profile of the correspondent 
terminal (25); 

generating a visitor list entry for the corre- 
spondent tenninal (25) based on a sen/ice pro- 
file and binding cache infonnation relating to 
path optimization; and 

returning a registration acknowledgment to the 
correspondent terminal (25). 

24. A proxy correspondent node (24) device which ver- 
ifies the state of a correspondentterminal (25) when 
the correspondent tenninal (25) is registered with a 
networt< and the correspondent terminal (25) may 
communicate with a mobile tenninal (12) In a net- 
work composed of a plurality of sub-networks and 
continues to communicate even when the mobile 
temninal (1 2) moves from one sub-network (1 ) to an- 
other sub-networic (2), characterized by: 

means for setting a visit state flag to an active 
state when the correspondent tenninal (25) Is 
transmitting packets during a registration proc- 
ess; 

means for monitoring the flow of packets trans- 
mitted from the correspondent terminal (25); 
means for setting the visit state flag to a pend- 
ing state when the monitoring does not detect 
a packet flow for a predetennined time period; 
means for setting the visit state flag to a left ar- 
ea state when the monitoring does not detect a 
packet flow for another predetennined time pe- 
riod and the visit state flag is in the pending 
state; 

means for setting the visit state flag to the active 
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state when the monitoring detects a packet flow 
when the visit state flag is In the pending state 
and before the another predetennined time pe- 
riod; and 

means for deleting a visitor list entry for the cor- 
respondent temriinal (25) based on a sen/Ice 
profile and binding cache Infonmation relating 
to path optimization when the visit state flag is 
in the left area state. 

25. A proxy correspondent node (24)devlce which ver- 
ifies the state of a correspondent tenminal (25) when 
the correspondent tenninal (25) is registered with a 
network and the con-espondent tenninal (25) may 
communicate with a mobile terminal (12) in a net- 
work composed of a plurality of sub-networks and 
continues to communicate even when the mobile 
terminal (12) moves from one sub-network (1) to an- 
other sub-nelwork (2), characterized by: 

means for setting a visit state flag to an active 
state when the conrespondent temninal (25) is 
transmitting packets during a registration proc- 
ess: 

nneans for detecting a packet transmitted from 
the correspondent temninal (25); 
means for setting a timestamp indicating the 
time of transmission of the detected packet; 
means for monitoring a time difference be- 
tween the timestamp and a current time; 
means for detemiining the correspondent ter- 
minal (25) no longer transmitting packets when 
the time difference is greater than a predeter- 
mined value; and 

means for deleting a visitor list entry for the cor- 
respondent temninal (25) based on a service 
profile and binding cache infonmation relating 
to path optimization when the visit state flag is 
in the left area state. 

26. A mobile communications method for providing 
service control and path optimization of a corre- 
spondent tenninal (25) communicating with a mo- 
bile terminal (12) in a network composed of a plu- 
rality ot sub-networks and for continuing to commu- 
nicate even when the mobile tenminal (12) moves 
from one sub-nelwork (1) to another sub-nelwork 
(2), characterized by: 

authentteating the correspondent terminal (25); 
retrieving a sen/ice profile of the correspondent 
tomninal (25); 
monitoring packets; 

determining whether the monitored packets are 
binding cache management messages corre- 
sponding to the correspondent terminal (25); 
and 

storing information received in the binding 



cache management messages in a proxy 
cache corresponding to the correspondent ter- 
minal (25). 

5 27. The mobile communications method of claim 26, 
further characterized by: 

performing operations and functions which 
are requested by the correspondent tenninal (25) 
according to the stored infonnation and the servtee 
10 profile information . 

28. The mobile communications method of claim 26, 
further characterized In that the detennining step 
further includes: 

15 

detenmining whetherthe monitored packets are 
binding cache management messages des- 
tined for the correspondent terminal (25), and 
when delemnined thai the binding cache man- 
20 agement messages are destined for the corre- 

spondent tenninal (25) and a corresponding 
entry In the proxy cache does not currently ex- 
ist, then 

generating the corresponding entry in the proxy 
25 cache; 

further generating a binding acknowledge mes- 
sage; and 

transmitting the generated message to a home 
agent of the mobile terminal (12). 

30 

29. A proxy communication unit providing communica- 
tion services for a correspondent terminal (25) that 
is communfcating with a mobile temninal (12) 
through a communication network, said proxy com- 
35 munication unit being part of the communication 
networi<, said proxy communication unit character- 
ized by: 



a controller for authenticating the correspond- 
40 ent tenninal (25), verifying and setting the serv- 

ices to be provided to the correspondent termi- 
nal (25) and Issuing a communication authori- 
zation to the correspondent terminal (25); and 
a message handling unit for generating and re- 
45 celving packets to and from distributed physical 

nodes to exchange information required in pro- 
viding the communication services for the cor- 
respondent temninal (25) that is communicating 
with the mobile tenninal (12), including verify- 
so ing and setting the services to be provided to 
the correspondent tenninal (25) among the dis- 
tributed physical nodes. 

30. The proxy communication unit of claim 2g, further 
55 characterized by: 

a link layer authenticating server (23) for pro- 
viding authenticating infonmation to said con- 
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31. 



trollen and 

a service profile database (27) that stores a 
service profile of the correspondent tenminal 
(25). 

The proxy communication unit of claim 30, further 
characterized In that a service profile of the con-e- 
spondent terminal (25) comprises an identifier for 
the correspondent terminal (25), and a sen/ice 
blocl< that describes the specific services to be pro- 
vided to the correspondent terminal (25). 



32. The proxy communication unit of daim 31, further 
characterized in that the service block Includes a 
service type, policy Infonnatlon and infomiation 
specific to the type of service to be provided. 



33 



34. 



The proxy communication unit of claim 29. wherein 
Ihe controller further characterized by: 

a cache management unit for storing and 
managing a binding cache con-esponding to the 
correspondent temiinal (25) and containing infor- 
mation of the mobile temnlnal (12). 

The proxy communication unit of claim 33, wherein 
the cache management unit further characterized 
by: 

a detecting unit for detecting and receiving a 
binding cache message corresponding to the 
correspondent terminal (25) and containing in- 
fonmation of the mobile temnlnal (12); 
a generating unit for generating an entry in a 
cache table If an entry containing the received 
binding cache infonnation does not exist; and 
an updating unit for updating the cache table 
with the received binding cache Infonnation if 
an entry does exist. 



35. The proxy communication unit of claim 34. further 
characterized by: 

a cache storage unit for storing at least one of 
the cache table, a visitor list and the service profile. 



36. 



The proxy communication unit of claim 29, wherein 
the controller further characterized by: 

a lunneling unll for generating a lunnel packet 
including a care-of -ad dress of the mobile terminal 
(12). 



37. The proxy communication unit of claim 29, further 
characterized in that the controller is further char- 
acterized by: 

a mobile agent unit for dynamically registering 
and deleting a registration of the correspondent ter- 
minal (25) where the con-espondent temninal (25) 
implements a mobile IP protocol as a communica- 
tion protocol. 
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38. The proxy communication unit of claim 29, further 
characterized in that the controller is further char- 
acterized by: 

a visit state unit for verifying that the corre- 
spondent tennlnal (25) is stilMn an area where the 
proxy communteation unit provides communication 
sen/ices for the correspondent temninal (25). 

39. The proxy communication unit of claim 38, further 
characterized in that the visit state unit is further 
characterized by: 

a packet monitoring unit for monitoring packet 
transmission from the con-espondent temninal (25), 
wherein when a packet from the correspondent ter- 
minal (25) is not detected for a predetemnlned peri- 
od of time the corespondent temninal (25) Is deter- 
mined to have left the area where the proxy com- 
munication unit provides communication services 
for the mobile temiinal (12) and the proxy commu- 
nication unit deletes a registration of the corre- 
spondent terminal (25). 



40. The proxy communication unit of claim 38, further 
characterized in that tho visit state unit is further 
^5 characterized by: 



a packet monitoring unit for monitoring packet 
transmission from the correspondent temninal 
(25) and setting a visit state flag to a pending 
state when a packet from the correspondent 
temiinal (25) is not detected for a predeter- 
mined period of time; and 
a determination timer, started when the visit 
state flag changes to the pending state, where- 
in when the packet monitoring unit does not de- 
tect any packets from the correspondent termi- 
nal (25) before the detemnination timer expires 
the visit state flag is set to out of area and the 
proxy communication unit deletes a registration 
of the correspondent temninal (25). 
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41. The proxy communication unit of claim 38. further 
characterized in that the visit state unit is further 
characterized by: 

a packet monitoring unit for monitoring packet 
transmission from the correspondent tennlnal (25) 
and storing a lime of transmission of a packet, 
wherein when a difference between a present time 
and the time of transmission is greater than a pre- 
detennined period of time the correspondent tennl- 
nal (25) is detemnined to have left the area where 
the proxy communication unit provides communica- 
tion services for the mobile tennlnal (12) and the 
proxy communication unit deletes a registration of 
the correspondent terminal (25). 

42. A proxy correspondent node device (24) (proxy CN) 
which fonms a communication system with a corre- 
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spondent terminal (25), and provides communica- 
tion services for a correspondent terminal (25) tliat 
is communicating witii a mobile node (12), said 
proxy CN (24) being part of a communication net- 
work, said proxy CN (24) characterized by: 

a first communication port for communicating 
with the correspondent terminal (25); 
a second communication port for communicat- 
ing with the communication network; and 
a controller for controlling the transmitting/re- 
ceiving of messages in the first communication 
port and the second communication port and 
for receiving a request message from the cor- 
respondent terminal (25) to communicate with 
the mobile node (12), authenticating the conre- 
spondent temninal (25), verifying and setting 
the services to be provided to the correspond- 
ent terminal (25) and issuing a communication 
authorization to the correspondent terminal 
(25). 



10 



47. The proxy CN devce (24) of claim 42, further char- 
acterized in that the controller Is further character- 
ized by: 

atunneling unit for generating atunnel packet 
including a care-of-address of the mobile node (1 2), 

48. The proxy CN device (24) of claim 47, further char- 
acterized in that the tunneling unit encapsulates a 
packet received from the correspondent terminal 
(25) and destined for the mobile node (12) within 
another packet with the care-of-address of the mo- 
bile node (12). 
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20 



43. The proxy CN device (24) of claim 42, further char- 
actorizcd in that the controller when authenticating 
the correspondent terminal (25) accesses a link lay- 
er authenticating server (23) for providing authenti- 
cating infomnatlon to said controller; and a sen/Ice 
profile database that stores a servtee profile of the 
correspondent terminal (25). 

44. The proxy CN device (24) of claim 42, further char- 
acterized in that the controller is further character- 
ized by: 

a cache management unit for storing and 
managing a binding cache corresponding to the 
correspondent terminal (25) and containing infor- 
mation of the mobile node (12). 

45. The proxy CN device (24) of claim 44, further char- 
acterized in that the cache management unit is fur- 
ther characterized by: 

a detecting unit for detecting and receiving a 
binding cache message corresponding to the 
correspondent temninal (25) and containing in- 
formation of the mobile node (12); 
a generating unit for generating an entry in a 
cache table if an entry containing the received 
binding cache information does not exist; and 
an updating unit for updating the cache table 
with the received binding cache information if 
an entry docs exist. 

46. The proxy CN device (24) of claim 45, further char- 
acterized by: 

a cache storage unit for storing at least one of 
the cache table, a visitor list and the service profile. 
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49. The proxy CN device (24) of claim 42, further char- 
acterized in that the controller is further character- 
ized by: 

a message handling unit for generating and 
receiving packets to and from distributed physical 
nodes to exchange information required in provid- 
ing the communication services for the correspond- 
ent temninal (25) that is communicating with the mo- 
bite node (12), including verifying and setting the 
services to be provided to the correspondent termi- 
nal (26) among the distributed physical nodes. 

50. The proxy CN device (24) of claim 42, further char- 
acterized in that the controller Is further character- 
ized by: 

a mobile agent unit for dynamically registering 
and deleting a registration of the correspondent ter- 
minal (25) where the correspondent terminal (25) 
implements the mobile IP protocol in communicat- 
ing with the proxy CN device (24). 

51 . The proxy CN device (24) of claim 42, further char- 
acterized in that the controller is further character- 
ized by: 

a visit state unit for verifying that the corre- 
spondent temninal (25) is still In an area where the 
proxy CN device (24) provides communication serv- 
ices for the correspondent terminal (25). 

52. A proxy correspondent node device (24) to accom- 
modate a con-espondent terminal (25) which makes 
a communication with a mobile terminal (12), char- 
acterized by: 

means for hunting binding information about 
the mobile temninal (12), which is transfen-ed 
from the home agent (26) of the mobile temninal 
(12) to the correspondent terminal (25); and 
means for processing data packets from the 
correspondent terminal (25) to the mobile ter- 
minal (12) based on the binding infomnation. 

53. The proxy correspondent node device (24) of claim 
52, further characterized by: 

means for transmitting a binding acknowl- 
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edge message to the home agent (26), which has 
a request to the- home agent (26) that subsequent 
binding infonmation should be transmitted to the 
proxy con^espondent node device (24). 

5 

54. A correspondent tenninal (25) to communicate with 
a mobile temiinal (12) via a proxy correspondent 
node device (24), characterized by: 

means for detecting a binding Information from io 
a home agent (26) which is accommodated in 
the same network as the mobile terminal (12) 
is accommodated; and 

means for transfen^ing the binding information 
to the proxy correspondent node device (24). is 
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(54) Mobile communications system and method thereof 



(57) Providing a network communteatlons system, 
which extensively supports a mobile temiinal (12). A 
proxy CN (24) being a router (24) is arranged between 
a con-espondent terminal (25) (CN) and a home agent 
(26) which directly corresponds to the conrespondent 
temiinal (26) (CN). The CN (25) accesses the proxy CN 
(24) when receiving a service using the Mobile IP. The 



CN (25) Is authenticated by a link layer authenticating 
server (23) which references a sen/ice profile DB (27), 
and makes a connection to a network (20). Communi- 
cation with a mobile temiinal (12) (MN) being a commu- 
nication partner is made via the proxy CN (24). In addi- 
tion, a packet transmission by tunneling is performed by 
the proxy CN (24). 
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